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TELNET BINARY TRANSMISSION 


This RFC specifies a standard for the ARPA Internet community. Hosts on 
the ARPA Internet are expected to adopt and implement this standard. 


1. Command Name and Code 
TRANSMIT-BINARY 0 
2. Command Meanings 


IAC WILL TRANSMIT-BINARY 


The sender of this command REQUESTS permission to begin 
transmitting, or confirms that it will now begin transmitting 
characters which are to be interpreted as 8 bits of binary data by 
the receiver of the data. 


IAC WON’ T TRANSMIT-BINARY 


If the connection is already being operated in binary transmission 
mode, the sender of this command DEMANDS to begin transmitting 
data characters which are to be interpreted as standard NVT ASCII 
characters by the receiver of the data. If the connection is not 
already being operated in binary transmission mode, the sender of 
this command REFUSES to begin transmitting characters which are to 
be interpreted as binary characters by the receiver of the data 
(i.e., the sender of the data demands to continue transmitting 
characters in its present mode). 


A connection is being operated in binary transmission mode only 
when one party has requested it and the other has acknowledged it. 


IAC DO TRANSMIT-BINARY 
The sender of this command REQUESTS that the sender of the data 
start transmitting, or confirms that the sender of data is 
expected to transmit, characters which are to be interpreted as 8 
bits of binary data (i.e., by the party sending this command). 

IAC DON’T TRANSMIT-BINARY 
If the connection is already being operated in binary transmission 


mode, the sender of this command DEMANDS that the sender of the 
data start transmitting characters which are to be interpreted as 
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standard NVT ASCII characters by the receiver of the data (i.e., 
the party sending this command). If the connection is not already 
being operated in binary transmission mode, the sender of this 
command DEMANDS that the sender of data continue transmitting 
characters which are to be interpreted in the present mode. 


A connection is being operated in binary transmission mode only 
when one party has requested it and the other has acknowledged it. 


3. Default 
WON’ T TRANSMIT-BINARY 
DON’T TRANSMIT-BINARY 
The connection is not operated in binary mode. 
4. Motivation for the Option 


It is sometimes useful to have available a binary transmission path 
within TELNET without having to utilize one of the more efficient, 
higher level protocols providing binary transmission (such as the 
File Transfer Protocol). The use of the IAC prefix within the basic 
TELNET protocol provides the option of binary transmission ina 
natural way, requiring only the addition of a mechanism by which the 
parties involved can agree to INTERPRET the characters transmitted 
over a TELNET connection as binary data. 


5. Description of the Option 


With the binary transmission option in effect, the receiver should 
interpret characters received from the transmitter which are not 
preceded with IAC as 8 bit binary data, with the exception of IAC 
followed by IAC which stands for the 8 bit binary data with the 
decimal value 255. IAC followed by an effective TELNET command (plus 
any additional characters required to complete the command) is still 
the command even with the binary transmission option in effect. IAC 
followed by a character which is not a defined TELNET command has the 
same meaning as IAC followed by NOP, although an IAC followed by an 
undefined command should not normally be sent in this mode. 


6. Implementation Suggestions 


It is foreseen that implementations of the binary transmission option 
will choose to refuse some other options (such as the EBCDIC 
transmission option) while the binary transmission option is in 
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effect. However, if a pair of hosts can understand being in binary 
transmission mode simultaneous with being in, for example, echo mode, 
then it is all right if they negotiate that combination. 


It should be mentioned that the meanings of WON’T and DON’T are 
dependent upon whether the connection is presently being operated in 
binary mode or not. Consider a connection operating in, say, EBCDIC 
mode which involves a system which has chosen not to implement any 
knowledge of the binary command. If this system were to receive a DO 
TRANSMIT-BINARY, it would not recognize the TRANSMIT-BINARY option 
and therefore would return a WON’T TRANSMIT-BINARY. If the default 
for the WON’T TRANSMIT-BINARY were always NVT ASCII, the sender of 
the DO TRANSMIT-BINARY would expect the recipient to have switched to 
NVT ASCII, whereas the receiver of the DO TRANSMIT-BINARY would not 
make this interpretation. 


Thus, we have the rule that when a connection is not presently 
operating in binary mode, the default (i.e., the interpretation of 
WON’T and DON’T) is to continue operating in the current mode, 
whether that is NVT ASCII, EBCDIC, or some other mode. This rule, 
however, is not applied once a connection is operating in a binary 
mode (as agreed to by both ends); this would require each end of the 
connection to maintain a stack, containing all of the encoding-method 
transitions which had previously occurred on the connection, in order 
to properly interpret a WON’T or DON’T. Thus, a WON’T or DON’T 
received after the connection is operating in binary mode causes the 
encoding method to revert to NVT ASCII. 


It should be remembered that a TELNET connection is a two way 


communication channel. The binary transmission mode must be 
negotiated separately for each direction of data flow, if that is 
desired. 


Implementation of the binary transmission option, as is the case with 
implementations of all other TELNET options, must follow the loop 
preventing rules given in the General Considerations section of the 
TELNET Protocol Specification. 


Consider now some issues of binary transmission both to and from 
both a process and a terminal: 


a. Binary transmission from a terminal. 


The implementer of the binary transmission option should 
consider how (or whether) a terminal transmitting over a TELNET 
connection with binary transmission in effect is allowed to 
generate all eight bit characters, ignoring parity 
considerations, etc., on input from the terminal. 
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b. Binary transmission to a process. 


The implementer of the binary transmission option should 
consider how (or whether) all characters are passed to a 
process receiving over a connection with binary transmission in 
effect. As an example of the possible problem, TOPS-20 
intercepts certain characters (e.g., ETX, the terminal 
control-C) at monitor level and does not pass them to the 
process. 


c. Binary transmission from a process. 


The implementer of the binary transmission option should 
consider how (or whether) a process transmitting over a 
connection with binary transmission in effect is allowed to 
send all eight bit characters with no characters intercepted by 
the monitor and changed to other characters. An example of 
such a conversion may be found in the TOPS-20 system where 
certain non-printing characters are normally converted to a 
Circumflex (up-arrow) followed by a printing character. 


d. Binary transmission to a terminal. 


The implementer of the binary transmission option should 
consider how (or whether) all characters received over a 
connection with binary transmission in effect are sent toa 
local terminal. At issue may be the addition of timing 
characters normally inserted locally, parity calculations, and 
any normal code conversion. 
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